[docs] 알림(Notification) 도메인 PRD 역설계 (specs/006-notification-domain)#359
[docs] 알림(Notification) 도메인 PRD 역설계 (specs/006-notification-domain)#359buzz0331 wants to merge 1 commit into
Conversation
- 운영 중인 알림 도메인을 사용자 관점으로 정형화 (신규 기능 정의 아님) - User Story 5건 (P1: 알림 센터·읽음 라우팅·디바이스 토큰 등록·트리거 수신, P2: 디바이스별 수신 여부 토글) - Functional Requirements 21건 (FR-001 ~ FR-021) - 측정 가능한 Success Criteria 7건, Edge Cases 10건, Assumptions 11건 - 본 PRD의 본질: 트리거 수신 이후의 알림 동작 (트리거 발화 조건은 발화 도메인 PRD가 책임) - 알림 트리거 카탈로그 15종 명문화: FEED 6종(팔로우/피드 좋아요/댓글/답글/댓글 좋아요/팔로잉 새 피드), ROOM 9종(새 참여자/모집 조기 마감/활동 시작/기록·투표 시작/ 게시글 댓글·답글·좋아요/댓글 좋아요) - 디바이스 단위 수신 여부 토글 정책: 같은 사용자라도 디바이스별 독립 - 외부 푸시 채널(현재 FCM)은 벤더 중립 추상화 - 저장(알림 센터)과 전달(푸시)의 독립성 보장 (외부 장애 시에도 누적 손실 X) - 알림 보존 정책 명문화: 현재는 평생 누적·수동 삭제 미제공 향후 최근 N일 자동 삭제 도입 예정 (개정 트리거로 Assumptions에 명시) - 트리거 발화 도메인·댓글·좋아요·사용자 라이프사이클은 명시적 범위 외
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
- "팔로잉한 사용자가 새 피드를 작성함" 트리거를 본 도메인 책임으로 명시 (공개 피드 생성 성공 시 작성자의 팔로워들에게 발화, 비공개·수정·삭제는 미발화) - 좋아요·댓글로 인한 알림 트리거의 책임 분리 명확화 (좋아요 공통 도메인, 댓글 도메인 책임) - 알림 도메인 PRD(#359)의 트리거 카탈로그(FEED 6종)와 정합
- "새 기록 작성됨" 트리거: 기록 작성 성공 시 같은 방의 다른 참여자 (작성자 제외)에게 발화. 수정·삭제는 미발화 - "새 투표 시작됨" 트리거: 투표 생성 성공 시 같은 방의 다른 참여자 (작성자 제외)에게 발화. 참여·취소·항목 변경·수정·삭제는 미발화 (생성 1회당 1건) - 댓글·좋아요로 인한 알림 트리거 책임 분리 명확화 (댓글 도메인, 좋아요 공통 도메인 책임) - 알림 도메인 PRD(#359)의 트리거 카탈로그와 정합
- "새 참여자" 트리거: 방 참여 성공 시 호스트에게 발화. 참여 취소(나가기)는 미발화 (참여 1회당 1건) - "모집 조기 마감" 트리거: 호스트가 closeRoomRecruit으로 RECRUITING -> IN_PROGRESS 전환 시 호스트 제외 참여자에게 발화 - "활동 시작" 트리거: IN_PROGRESS 진입 시 참여자에게 발화 (조기 마감과 함께 발화될 수 있는 별개 트리거) - 알림 도메인 PRD(#359)의 트리거 카탈로그(ROOM 9종 중 3종)와 정합
1 participant
Summary
운영 중인 알림(Notification) 도메인을 사용자 관점에서 역설계해 PRD로 정형화한 여섯 번째 산출물.
신규 기능 정의가 아닌 기존 구현을 "이래야 한다"로 문서화하는 작업.
무엇이 추가되는가
specs/006-notification-domain/spec.mdspecs/006-notification-domain/checklists/requirements.md본 PRD의 본질
알림 도메인은 수동적이다. 다른 도메인(피드/팔로우/방/RoomPost/댓글/좋아요)에서 발화된 트리거를 받아, 그 트리거를 알림으로 가공해 (a) 알림 센터에 누적하고 (b) 디바이스에 푸시한다.
PRD 구성
핵심 결정
알림 트리거 카탈로그 (User Story 5)
15종 트리거를 카테고리·발화 도메인·라우팅 대상별로 명문화. 다른 PRD가 "트리거를 발화한다"고 명시한 부분(예: 팔로우 PRD #355)이 이 카탈로그와 정합해야 함.
디바이스 단위 수신 여부 (FR-013)
같은 사용자가 디바이스 A는 켜고 B는 끌 수 있음. 알림 센터 누적은 수신 여부와 무관(앱 안에서는 보임, 푸시만 차단).
저장과 전달의 독립성 (FR-019, SC-006)
외부 푸시 채널(현재 FCM) 일시 장애로 푸시 전달이 실패해도 알림 센터에 누적된 알림은 손실되지 않음. 사용자 가시성 보장.
알림 보존 정책 (FR-021)
현재 정책: 평생 누적, 자동 삭제·만료·사용자 수동 삭제 모두 미제공.
향후 도입 예정 (Assumptions에 명시):
읽음 처리의 멱등성과 라우팅 보장 (FR-005, FR-006)
읽음 처리는 최초 1회만 상태를 바꾸지만, 라우팅 정보는 매번 응답된다. 클라이언트는 이미 읽은 알림을 다시 클릭해도 의도된 화면으로 이동 가능.
범위 외 (의도적)
누적 PRD 진행 상황
Test plan